Guión para la presentación de evaluación del Sprint 3

Guión preliminar por	Presentador	Tiempo
Nicolás Herrera	X	X
Álvaro González	X	X

Inicio + Killer Opener

Figura 1. Killer opener (parte 1).

Hoy vamos a contaros un poco la historia de AL. AL es un chico apasionado por la informática que ha vivido en un entorno tenso durante su adolescencia. Sus amigos se vieron envueltos en el consumo de drogas desde una edad muy temprana y AL quiso evitar que se adentraran en ese mundo, pero no tenía un buen plan para logralo.

Figura 2. Killer opener (parte 2).

Buscando en internet,AL descubrió a ACAT, una asociación que ayuda a personas con problemas de adicción. Sin embargo, las gestiones que hacía ACAT eran muy lentas y no podían asistir a todos sus amigos a la vez. Así que se decidió a ayudarlos construyendo una aplicación para sus gestiones, pero estaba sólo para hacerlo.

Figura 3. Portada de la presentación.

Cuando nos enteramos de esto enseguida quisimos echarle una mano a AL y así fue como nació Harmony, una empresa que lucha por traer a las ONGs a la nueva era de la gestión automatizada, y para enseñároslo estamos hoy nosotros aquí, el es mi compañero Alberto, yo soy Nicolás, y venimos en representación de Harmony, empresa que actualmente se encuentra trabajando con dos ONGs, ACAT y CyC.

Figura 4. Contexto.

Y es que vosotros poneros en la situación: os encontráis administrando todos los datos una empresa, con métodos que desconocéis, se os hacen incómodos, y de repente os aparece una empresa que os va a proporcionar una web cómoda, fácil de usar, bonita visualmente y que os va a proporcionar una eficiencia a la que antes ni os acercabais.

Análisis de los competidores

Figura 5. Competidores.

Nosotros hemos identificado dos empresas que la ofrecen. Analicemosla. La primera es Stockio proporciona un software para la gestión de inventarios y almacenes, pero no para la gestión de beneficiarios, cosa que sí hace Pantrysoft, pero al estar ubicada en los Estados Unidos, no les garantiza a las ONGs españolas el cumplimiento de las leyes de protección de datos europeas, tras lo que deducimos que estas empresas no ofrecen una solución que se pueda adaptar a todas las necesidades de cada ONG.

Figura 6. Herramientas Open Source.

Y por otra parte, existen una serie de herramientas open source que consideramos que podrían ser de utilidad para las ONGs, como Django-CRM o CiviCRM. Pero tras analizarlas hemos visto que están más orientadas a la gestión de clientes empresariales y que no se adaptan a las necesidades de las ONGs. Y aquí es cuando entramos nosotros,ofreciendo una solución que se adapta a las necesidades de cada ONG.

Anuncio

Figura 7. Anuncio (parte 1).

Y qué mejor forma de mostraros nuestro producto, que con un pequeño spot publicitario.

Figura 8. Anuncio (parte 2).

Aspectos legales del Proyecto

Figura 9. Aspectos legales del proyecto.

Continuando con algo más serio, los aspectos legales de nuestro proyecto. Para esto, hemos hecho 2 divisiones de nuestro marco legal, el uso de nuestro servicio y el uso únicamente de nuestro software.

• Use of Service: Para esta en concreto se han definido tanto el Customer Agreement, el cual recoge todos los términos y condiciones a los que se somete un cliente al contratar un servicio de la empresa Harmony. Entre estos encontramos pagos y tarifas, acuerdos de nivel de servicio definidos en iTop, política de privacidad etc. A su vez, también definimos un documento de Protección de Datos, en el que nos comprometemos a proteger la privacidad y los datos de los clientes y usuarios que contraten un servicio. Este reglamento se fundamenta principalmente en la LOPD,s LOPDGDD y el RGPD. Todas las clausulas de estos documentos han sido analizadas mediante la herramienta Claudette, para asegurarnos de que estas no sean abusivas hacia ninguno de los dos lados.

• Without service: Por otro lado, si haces uso únicamente de nuestro software, te atienes a los términos en este caso no de nuestros términos y condiciones, sino de la licencia AGPL.

Plan de marketing inicial

Figura 10. Plan de marketing inicial.

Debido a que en las próximas semanas vamos a comenzar con las tareas de marketing, queremos comentaros el plan inicial que tenemos previsto. En primer lugar, lo que queremos vender como empresa es un servicio de desarrollo de aplicaciones personalizables para ONGs. Para promocionarnos, además de realizar anuncios como el que hemos visto previamente, tenemos pensado crear perfiles de nuestra empresa en las redes sociales más populares. Además, ya diponemos de una landing page en la que los usuarios pueden obtener más información acerca de nuestra empresa y de los servicios que ofrecemos (os dejaremos un QR al final de la presentación para que podáis acceder a ella). Pero, ¿cuáles son los objetivos que pretendemos alcanzar con este plan de marketing? Aumentar las ventas de nuestro servicio y establecer nuestra empresa como la mejor opción para las ONGs que necesiten una aplicación para gestionar sus datos.

TCO

Figura 11. TCO.

Respecto al TCO, en este caso se encuentra dividido en Capex y Opex. Por un lado, el Capex lo dividimos en Costes de Personal, de material, de licencia y de seguridad social. Por otro lado, en el opex encontramos los costes de despliegue, de api, de sla y de personal (GPDR y CM). Todo esto sumado a una contingencia del 15% da un TCO bienal de 97.7k.

ROI

Figura 12. ROI.

Y bien, 91.000€ no es poco dinero, nos hace falta estar seguros de que vamos a recuperar esta inversión. Por ello hemos hecho un análisis tratando de predecir el crecimiento de nuestra base de clientes y el retorno de la inversión en situaciones optimistas, pesimistas y más probables. Como veis en la gráfica, los costes son un poco más grandes al principio, en el periodo de desarrollo, pero conforme entramos en producción bajan, a la vez que aumentan los ingresos. Según hemos calculado nuestro servicio generaría más de lo que cuesta a partir de los 30 meses aproximadamente tanto en el escenario optimista como en el más probable, y en el pesimista, que asume un crecimiento prácticamente nulo de clientes, no parece que vayamos a recuperar la inversión.

Seguimiento de costes + Burndown

Figura 13. Estado actual.

En la última semana del sprint 3 el equipo ha trabajado en los puntos de historia planificados y se ha conseguido un progreso prácticamente ideal, aunque es cierto que estamos ligeramente adelantados respecto al número ideal de historias para esta semana. Por otra parte, el presupuesto consumido de esta semana ha sido inferior al de semanas anteriores, estando aún por encima del ideal pero empleando menos tiempo para la finalización de los puntos de historia. Esto concluye en un presupuesto que se acerca al ideal conforme avanza el proyecto, compensando así las sobrecarga de las primeras semanas, y un avance óptimo respecto a los puntos de historia

Figura 14. Burndown.

En el sprint 3, los miembros del equipo se han visto bastante implicados en completar las tareas en la fecha establecida. Esto se ve en un burndown que se puede observar ha ido evolucionando de manera casi constante y siempre cercano a lo ideal. Debido al desarrollo del proyecto en sprint anteriores donde la carga de trabajo ha sido superior al ideal, este sprint ha sido planificado para que los integrantes del equipo tengan un menor número de puntos de historia que completar, compensando así el trabajo dedicado al proyecto.

Equipo y estado del CA

Figura 15. Commitment Agreement (parte 1).

Figura 16. Commitment Agreement (parte 2).

Figura 17. Commitment Agreement (parte 3).

Continuamos con el Commitment Agreement, cuyo cumplimiento ha sido excelente tanto a nivel general como individual, quitando alguna semana puntual en la que algunos miembros han recibido algún aviso por no cumplir alguna de las cláusulas.

Figura 18. Nuevos roles.

Mencionar también, a los nuevos roles, el GDPR Manager, en este caso será Antonio Rodriguez, y el Comunnity Manager que será mi compañero aquí presente Alberto (Cuya pareja es CM real).

Changelog

Figura 19. Changelog.

Estos serían los cambios que se han implementado en la última semana del Sprint 3, que se mostrarán en la siguiente demostración.

Demo

Figura 20. Demo.

Retrospectiva

[Enlace entre la demo y la retrospectiva: la demo que acabamos de observar es el resultado del rendimiento y esfuerzo del equipo. Así que pasemos a hablar de ello.]

Rendimiento

Figura 21. Rendimiento en el Sprint 3.

Aquí podemos ver una gráfica que representa rendimiento del equipo durante el Sprint 3. Lo ideal es que la mayoría de burbujas se encuentren lo más a la derecha posible, pues esto implica una puntuación del rendimiento más elevada. De hecho, esto es lo que ocurre en este caso, por lo que podemos ver que el equipo ha tenido un buen rendimiento durante esta sprint.

Calidad

Figura 22. Análisis de calidad.

En cuanto a la medición de la calidad, nosotros hemos empleado la herramienta Codacy para que puntue la calidad de nuestro código. Como vemos, durante este Sprint 3 hemos seguido manteniendo el nivel de calidad más alto posible en cada uno de nuestros repositorios, como veníamos haciendo durante los primeros dos sprints. [Opcional: Esto es en parte debido a que tenemos automatizado un análisis de calidad de código que se ejecuta cada vez que se realiza una pull request, lo que nos alerta de posibles problemas de calidad de código antes de que se fusionen en la rama de desarrollo].

Gestión de problemas

Figura 23. Gestión de problemas.

Mantener una buena calidad de código no significa que no hayamos tenido problemas. Como podéis ver, nuestro compañero AL ha estado trabajando duro para resolver un problema relacionado con el alcance, y es que que durante este sprint 3 nos hemos dado cuenta de que nos faltaba tiempo para completar todas las tareas que habíamos planeado. Para solucionarlo, hemos tratado de replanificar para reducir el alcance, intentando que afecte lo menos posible a las expectativas del cliente. Siguiendo nuestra rúbrica para medir la calidad de la solución, hemos obtenido una puntuación de 4 sobre 5, lo que indica que hemos resuelto el problema de manera satisfactoria.

Replanificación del Sprint 3

Figura 24. Replanificación del Sprint 3.

Como acabamos de comentar, hemos tenido que replanificar durante el sprint 3, así que vamos a ver con más detalle en qué ha consistido esta replanificación. En primer lugar, hemos decidido no implementar las notificaciones push por falta de tiempo, pero hemos buscado una alternativa como es la implementación de filtros para obtener información relevante de forma más rápida. Por otro lado, hemos tenido que mover la tarea de los skeleton loaders al PPL, pues es una tarea que no consideramos prioritaria, y moverla al PPL nos ha permitido centrarnos en tareas más importantes durante este sprint 3.

Resultados del Sprint 3

Figura 25. Resultados del Sprint 3.

En cuanto a las tareas del Sprint 3, hemos completado todas las tareas que nos habíamos propuesto. Hemos elaborado un panel de estadísticas, hemos integrado una pasarela de pago para poder realizar donaciones a las ONGs y hemos implementado la verificación de email utilizando una API externa, y también hemos completado la tarea de los filtros que hemos mencionado anteriormente. Además, hemos estado atendiendo las solicitudes de cambios de nuestros usuarios pilotos, como la creación de un usuario maestro que sea el único con permisos para crear otros usuarios o la traducción de los excels a español. Por último, hemos convertido la aplicación en una PWA para que los usuarios puedan usarla sin necesidad de conexión a internet.

Reloj del proyecto

Figura 26. Reloj del proyecto (parte 1).

En relación al tiempo invertido, durante las dos semanas del sprint 3 hemos dedicado unas 230 horas al proyecto. Es cierto que es algo menos de lo esperado (340 horas), pero esto se entiende mejor si vemos el tiempo total invertido en el proyecto hasta ahora.

Figura 27. Reloj del proyecto (parte 2).

Como vemos, aún estamos unas 200 horas por encima de lo previsto para estas fechas. Esto se debe a que durante las primeras semanas invertimos más tiempo del previsto, por lo que en estos momentos estamos reduciendo un poco el ritmo de trabajo.

Plan de pruebas

Figura 28. Plan de pruebas.

Otro aspecto importante en nuestro proyecto es la realización de pruebas. Por la parte del backend, nos hemos centrado en hacer tests unitarios y de integración, y además, durante este sprint 3 hemos realizado tests de carga para comprobar cómo se comporta la aplicación con un número elevado de usuarios. Por la parte del frontend, hemos estado realizando tests unitarios, empleando mocks para simular el comportamiento funciones como las llamadas a la API. También hemos realizado tests para comprobar el correcto renderizado de los componentes de la aplicación. [Opcional: cabe mencionar que también tenemos definida una metodología para realizar las pruebas, de forma que todas las funcionalidades que se suben a la rama de desarrollo deben estar acompañadas de tests que las validen. Además, estos tests deben ser realizados por un miembro del equipo que no sea el desarrollador de la funcionalidad en cuestión. Consideramos que esto sirve para aumentar la calidad de nuestro código].

Figura 29. Tests de carga.

Aprovechando que durante este último sprint tenemos la novedad de los tests de carga, os mostramos un ejemplo de los resultados de uno de estos tests. En concreto, estos son los resultados de un test de carga que simula hasta cien mil usuarios realizando peticiones GET Y POST sobre el recurso de entregas, las cuales son la peticiones que más recursos consumen. Como vemos, tenemos un tiempo medio de respuesta de 5 segundos con los cien mil usuarios, y un porcentaje de fallos menor al 1 %, lo que nos indica que la aplicación es capaz de soportar un número elevado de usuarios sin grandes problemas.

Usuarios piloto

Estado

Figura 30. Estado de los usuarios piloto.

Con respecto a los usuarios piloto, que en nuestro caso son tanto los compañeros del grupo 1 de ISPP como los miembros de las ONGs a las que estamos prestando servicio, ACAT y Cirio y Costal, están tanto contactados como informados como involucrados. Como podemos ver, actualmente tenemos un 67 % de participación de los usuarios piloto, y esto se debe a que hemos recibido feedback tanto de Cirio y Costal como del grupo 1, pero por incompatibilidad horaria no hemos podido recopilar feedback de la ONG ACAT durante el sprint 3. Sin embargo, mañana mismo hemos podido concertar una reunión con ellos, por lo que el porcentaje de participación se situará en el 100 %. Es importante mantener este porcentaje lo más alto posible ya que el feedback recibido nos ayuda a mejorar nuestro producto. Además, todos los usuarios han firmado el acuerdo de compromiso conjunto que establece una serie de acuerdos relacionados con el recibimiento de feedback, como vamos a ver a continuación.

Acuerdo de compromiso

Figura 31. CA de los usuarios piloto (parte 1).

Hay dos cláusulas comunes en el Acuerdo de Compromiso de cada tipo de usuario piloto: cumplir las deadlines y tener una comunicación fluida. Para el caso concreto de los usuarios del grupo 1, también deben usar iTop, Clockify y en caso de que no nos guste el tipo de feedback que nos dan, se comprometen a cambiar de revisor.

Figura 32. CA de los usuarios piloto (parte 2).

Para el caso de las ONGs, lo que deben hacer es probar el prototipo de la aplicación que les corresponda.

Ranking de feedback

Figura 33. Ranking de feedback.

Tras el feedback recibido de los usuarios piloto, hemos seguido nuestro mecanismo de gestión de feedback para priorizar cada una de las peticiones que nos van llegando. Aquí podemos ver un ranking con los cambios más relevantes que nos han solicitado: mostrar estadísitcas específicas que son requeridas por el Banco de Alimentos a las ONGs, importar y exportar familias desde y hacia Excel, y mostrar un mensaje de confirmación antes de eliminar una familia.

Calendario

Figura 34. Calendario de usuarios piloto (abril).

Este es el calendario de usuarios piloto que hemos planificado para el mes de abril. Los días marcados en azul son los días en los que los usarios piloto van a probar la aplicación y los días marcados en amarillo son los días en los que vamos a analizar el feedback que nos han proporcionado. Como vemos, durante esta semana los usuarios están probando la aplicación, por lo que esperamos recibir su feedback en los próximos días.

Figura 35. Calendario de usuarios piloto (mayo).

También podemos ver el calendario de usuarios piloto para el mes de mayo. En este caso, solo hemos planificado una semana de pruebas de la aplicación, tras la cual esperamos recibir el feedback final de los usuarios pilotos para ir concretando la entrega final del proyecto en la fecha prevista.

Planificación de la fase PPL

Figura 36. Planificación de la fase PPL.

De cara a la fase PPL (Preparing Project Launch) no tenemos pensado realizar grandes cambios en la aplicación, sino que vamos a centrarnos en preparar la aplicación para su lanzamiento. Para ello, vamos a elaborar un plan de lanzamiento, vamos a elaborar manuales de usuario y vamos a realizar una campaña de marketing. Lo único que tenemos pensado tocar en cuanto al código serían algunos cambios para mejorar la experiencia de usuario (donde se incluye por ejemplo la implementación de skeleton loaders o la mejora de estilos), y la implementación de aquellos cambios que nos soliciten los usuarios piloto y que consideremos que son necesarios para mejorar la aplicación.

Uso de la IA

Usos de esta semana

Figura 37. Uso de la IA.

En cuanto al uso de la IA, hemos seguido utilizando GitHub Copilot y ChatGPT para ayudarnos con el código, ChatGPT para ayuda en tareas de documentación y RemoveBG para eliminar el fondo de algunas de las imágenes de esta presentación.

Huella de carbono

Figura 38. Huella de carbono.

También hemos estado investigando acerca de la huella de carbono que generan las IAs que estamos utilizando. Hemos encontrado que cada query produce una emisión de CO2 de 4,32 gramos de CO2, por lo que hemos estimado que nuestro proyecto supone una emisión de algo más de 400 gramos de CO2 por semana (suponiendo que realizamos unas 100 queries semanales).

Cierre

Cumplimiento de objetivos

Figura 39. Cumplimiento de objetivos.

Para finalizar, vemos que hemos cumplido con los diferentes apartados que estaban previstos para la presentación. [Opcional: se pueden mencionar los diferentes apartados si se necesita alargar la presentación para llegar a los 15 minutos].

Fin de la presentación

Figura 40. Fin de la presentación.

Os dejamos nuestro correo electrónico por si tenéis alguna duda o sugerencia, y un código QR para que podáis acceder a nuestra landing page. ¡Muchas gracias por vuestra atención!